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(57) ABSTRACT 

The invention provides a new cost-effective and efficient 
framework for network management of telecommunications 
networks by monitoring the network-level concepts of 
routes and paths. The invention is embodied in a route and 
path management (RPM) system which includes a data 
collector for collecting data from the individual network 
elements, a management server for processing the routing 
data collected into manageable route and path objects and a 
graphical unit interface (GUI) for allowing a user to manage 
and monitor routes and paths in the IP network. By moni- 
toring routes and paths, the RPM provides network manag- 
ers with the added capability of troubleshooting, perfor- 
mance monitoring, service level planning and provisioning 
packet forwarding paths between any source-destination 
endpoints in a network. 
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ROUTES AND PATHS MANAGEMENT 

FIELD OF THE INVENTION 

The invention relates to network management and in s 
particular, to methods and apparatus for the management of 
routes and paths in telecommunications networks. 

BACKGROUND OF THE INVENTION 

In today's large telecommunications networks such as 
core networks used for Internet service providers (IMPS) or 10 
major corporate backbones, network management plays an 
important role in maintaining network stability, performance 
and efficiency. Network management is used to perform a 
variety of functions including the detection and correction of 
fault conditions, the identification, configuration and moni- 
toring of use of network devices for cost allocation and 
performance evaluation. 

Presently, the vast majority of networks are manager at 
the physical or device level by a centralized management 2Q 
entity commonly referred to as a network manager server 
(hereinafter "network manager") whereby devices in the 
network such as routers and physical layer interfaces are 
each individually polled by the network manager for status 
updates. However, in many situations, this process is not 25 
time -efficient. 

For example, in the event of a congestion point causing 
unusual traffic delays or a failures causing a traffic interrup- 
tion along a particular routing path, each network device 
located along that particular path and involved in the trans- 30 
mission of the traffic delayed or interrupted as a result of the 
congestion point or failure must be polled by the network 
manager to locate the source of the problem. Polling mul- 
tiple devices each time a problem arises along a particular 
routing path is therefore time-consuming and as a result, 35 
substantially lengthens the time necessary to solve the 
problem. 

Because polling of multiple network devices is time- 
consuming, most problems encountered in a network may 
deteriorate or improve by the time a network manager is able 40 
to track down the root of the problem, making it more 
difficult to ascertain its true nature. Moreover, in many cases, 
clients only report network problems long after their occur- 
rence which, by that time, may not be visible problems 
anymore. This is particularly true of congestion points which 45 
are intermittent by their very nature and only occur in heavy 
traffic conditions. 

In ascertaining the nature of a particular problem, it is 
often necessary for the network manager to determine which 
clients are affected and the manner in which these clients are 50 
affected. This typically requires a network-level analysis of 
each problem by considering the performance history of the 
particular routes and paths used by each client. A route is a 
static concept typically defined by a source endpoint and a 
destination endpoint in a network. By contract, a path is a 55 
dynamic concept associated with a particular route. A path 
is defined as the set of network devices and their respective 
interfaces traversed by traffic travelling in a particular direc- 
tion at any given point in time on the particular route. 

However, current device -level management applications 60 
do not provide the necessary tools for efficiently monitoring 
routes and paths. As a result, these problems become virtu- 
ally impossible to solve and may persist indefinitely. 
Therefore, there is a need to provide network operators with 
the ability to monitor the performance history of routes and 65 
paths for efficient troubleshooting of problems arising in a 
network. 



,867 Bl 

2 

Another drawback of the use of device-level management 
is that it does not address real-time performance issues at a 
routing path level which often arise in a network as a result 
of problems occurring at the device level such as congestion 
points and link or equipment failures. Device -level manage- 
ment only deals with performance issues for which the 
network devices are individually responsible. However, this 
"device-level view" does not provide a path-level under- 
standing of the overall real-time performance of all the 
devices defining a particular path of a particular route. 

For example, in correcting a congestion problem, device- 
level management does not address whether the data trans- 
mitted on a particular source-destination route follows the 
intended path which may have been specifically provisioned 
for it or whether it has been rerouted to an alternate path. 

When traffic is rerouted due to a failure in the network, 
another real-time performance issue not addressed by 
device -level management is whether the alternate path cho- 
sen has the requisite capacity for accommodating the traffic 
delayed or interrupted or whether the traffic as redirected 
will maintain the same level of service it had prior to being 
redirected. As network routes are currently sold to network 
clients with a specific quality of service (QoS), adequate 
configuration and path provisioning of network routes is 
becoming increasingly important. Therefore, there is a need 
for providing a network with adequate real-time perfor- 
mance monitoring and path provisioning capability for 
maintaining performance in a network and meeting ever 
increasing QoS demands. 

The need to deal with device-level problems in a more 
time-efficient manner and address real-time performance 
issues arising as a result of the occurrence of device -level 
problems has triggered the emergence of what is now known 
in network management as trace routing. Trace routing 
applications allow some form of network- level management 
of paths and routes by relying on test messages to perform 
path discovery of specified routes. In particular, current trace 
routing implementations determine the path likely to be 
followed by traffic for a particular source-destination route 
by sending one or more test packets from the source node to 
the destination node and summarizing the results. However, 
this method has a number of disadvantages. First, the trace 
routing of any given source-destination route can only be 
performed from the source node. Another disadvantage is 
that most network devices are not properly instrumented to 
do this function and do not treat the test packets with the 
same priority than normal traffic, Therefore, the results 
obtained with this method are not truly representative of 
how the network devices handle their respective traffic in 
real-time. As a result, there is a need for an improved 
network management system for managing and monitoring 
paths and routes in a network and also for monitoring the 
behaviour of network devices in real-time. 

SUMMARY OF THE INVENTION 

It is an object of the invention to obviate or mitigate one 
or more of the above identified disadvantages and short- 
comings of current network management applications. 

The invention provides a cost-effective and efficient new 
route and path management (RPM) framework for network 
management of telecommunications networks by monitor- 
ing the network-level concepts of routes and paths. By 
monitoring paths and routes in a network, the RPM system 
provides network managers with the added capability of 
troubleshooting, performance monitoring, service level 
planning and provisioning paths between any source- 
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destination endpoints (routes) in a network. In a preferred FIG. 7 is a flowchart of the main steps executed by the 

embodiment, the RPM system is incorporated in an Internet path trace algorithm used for discovering the paths of a 

protocol (IP) network and is designed to be operable in a specified route historically and in real-time; 

simple network management protocol (SNMP) environ- FIG> s & a 51ock diagram of ^ performance monitor 

ment. The RPM system is comprised of a data collector for 5 logic unit as implemented in the management server of the 

collecting routing data from the individual network devices, RPM system of FIG. 4 for providing real-time performance 

a management server for processing the routing data col- m0 nitoring of a specified route; 

lected into manageable route and path objects for tracing and n . L1 A ,. c c 

? ... j ♦ u * ♦ ■ .u 1. rlO. y is a block diagram of the performance monitor 

performance monitoring, a database lor storing the results , . . 4 ~ . . r A c 

1 ... • f c /( n im r n . 4 logic unit as implemented in the management server or the 

and a graphical unit interlace (OU I) lor allowing a user to 10 n nu * c ™* a • 1 c 

. j .1 ■ TTi »■ i j ■? 4 . RPM system of FIG. 4 providing historical performance 

trace routes and paths in the IP network and monitor routine •* • c / \ 6 F 

r r e monitonng of a specified route: 

performance. 0 r 

By comparison with device-level management F / G " 10 * * ™ ock 6i ^ m of the historical P ath & 

applications, the present invention advantageously allows Performance broker as implemented in the management 

the real-time determination of permissible paths having the 15 server of the RPN1 s y stem of FIG * and 

requisite capability for the transmission of data on a given FIG * U is a block diagram of a second embodiment of the 

set of routes and routing protocols. R p M system of FIG. 2. 

Yet another advantage of the present invention compared nuTAT r ™ nccpDiDTrnM ^ tut; 

to device-level management techniques is that it provides ^l^u^^U^jm^ 

means for storing and providing, on demand, route history 20 PKhbhRRbU LMBODIMEN ITS 

and path-level multi-metric performance history for future This invention provides a cost-efficient and effective 

provisioning and troubleshooting of the routes and paths framework for network management of telecommunications 

monitored. networks by monitoring the network-level concepts of 

Similarly to current device-level management routes and paths. According to a preferred embodiment, the 

applications, the invention allows real-time monitoring and 25 present invention is embodied as a route and path manage- 

reporting of device-level performance. Yet still another ment (RPM) system designed to be operable in a simple 

advantage of the present invention over device-level man- network management protocol (SNMP) environment, 

agement is that it also provides path-level real-time and ^ RPM system can be incorpora ted in any network 

historical performance of routes and paths monitored, topology or configuration. For simplicity however, the 

Yet still another advantage of the present invention over 30 invention will now be described only in relation to an 

device-level management techniques is that it provides Internet protocol network (hereinafter the "IP network"), 

means for raising or clearing quality of service (QoS) alarms This IP network is shown in FIG. 1 as 10. 

against routes and paths monitored. The Ip network 1Q illustrated therein is composed of a 

In another preferred embodiment, the RPM system as 35 pUJra iity of nodes commonly indicated by 11 and individu- 

described above also has a management information base a n y num bered 1 through 8. Each of these network nodes 11 

(MIB) in which the route and path objects managed by the ^ linked t0 others of lhe netW0 rk nodes 11 by one or more 

management server are made available to other network communication links respectively labelled A through L 

entities and applications via SNMR (A-L). Each such communication link A-L may be either a 

Yet still another advantage of the present invention is that 4Q permanent connection Dr a selectively enabled (dial-up) 

by using an MIB for SNMP storage of the route and path connection. Any or all of the network nodes 11 may be 

objects managed, the tracing and routing performance connected to one or more edge nodes commonly indicated 

results generated by the management server may be by 12 for communication with other nodes or networks (not 

remotely accessed by any SNMP entity. shown) located outside of the IP network 10. For example, 

Other aspects and features of the present invention will 45 in the IP network of FIG. 1, nodes 2, 7 and 8 are connected 

become apparent to those ordinarily skilled in the art upon to a respective edge node 12. These edge nodes are indi- 

review of the following description of specific embodiments vidually numbered 13, 14, 15. 

of the invention in conjunction with the accompanying The network nodes 11 each comprises a data processing 

figures. system (not shown) which provides data communications 

BRIEF DESCRIPTION OF THE DRAWINGS 50 services to all connected nodes, network nodes 11 and edge 

n f j ... c *u . mi u nodes 12, as well as providing decision units (not shown) 

Preferred embodiments of the invention will now be ... . , u j -h a * u * 1 j n \ , - . 

, j ... r . „ ^ 1 , 1 - . , within the node 11. At each network node 11, the decision 

described with reference to the attached drawings in which: ^ { serye tQ seUctivel route incomin ^ 

FIG. 1 is a block diagram of an Internet protocol network packets on Qne 0f more of the { communication links 

hereinafter the ( IP network ); $$ A _ L for transmission to other nodes n or edge nodes 12 

FIG. 2 is a block diagram of a first embodiment of the Such rout ing decisions are made in response to information 

route and path management (RPM) system of node 1 of the m me header of cach data packet rece i ved . 

IP network of FIG. 1; [n (he Jp network 10> thc overall management of the IP 

FIG. 3 is a diagram of the graphical user interface of the net work 10 of FIG. 1 is performed by a centralized network 

RPM system of FT G. 2; 60 mana g cme nt system which can be found in or attached to 

FIG. 4 is a more detailed block diagram of the RPM one 0 f the network nodes 11 shown in FIG. 1. For 

system of FIG. 2; clarity, the network management system will now be 

FIG. 5 is a block diagram of the path trace & monitor described below as being part of node 1 in reference to 

logic unit as implemented in the RPM system of FIG. 4; FIGS. 2 through 9 and as such, node 1 is hereinafter referred 

FIG. 6 is a flowchart of the main steps required for 65 to as the "network manager". Ho we ver, it is to be understood 

discovering the paths of a specified route historically and in that the network management system could alternatively be 

real- time; implemented in any other node 11 of the IP network 10 or 
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in the further alternative, implemented in multiple nodes 11 
of the IP network 10. 

In the IP network 10 of FIG. 1, the network manager 1 is 
responsible for executing management applications such as 
the integrated network management (INM) application for 
monitoring and controlling network elements or NEs. Net- 
work elements are devices such as the edge nodes 12, 
network nodes 11 and their associated routers and interfaces. 
In order to be managed by the network manager 1, these 
network elements are each assigned to a management agent 
responsible for performing the network management func- 
tions requested by the network manager 1. 

As is well known, the agents are responsible for accessing 
information about the network elements assigned to them 
and make it available to the network manager 1. For 
example, an agent might report the number of bytes and 
packets in and out of a particular network element, or the 
number of messages sent and received by that network 
element during a given time period. These variables are 
referred to as managed objects and are maintained in a 
database referred to as a management information base 
(MIB) unique to each network element. Therefore, when the 
network manager 1 requests information relating to a par- 
ticular element of the IP network 10, that information is 
obtained from the associated MIB via the agent assigned to 
the particular network element. In the following description 
of the IP network 10, the MTBs and associated agents are not 
always referenced specifically. However, it is to be under- 
stood that by referring to the network elements, reference to 
the associated MIBs and agents is implied. 

As noted above, the RPM system 20 of the IP network 10 
is implemented to be operable in an SNMP environment. 
Although not essential to this invention, tile SNMP imple- 
mentation is highly desirable for promoting interoperability 
and facilitate the exchanges of management information 
between the network manager 1 aid the agents of the 
respective network elements. 

Referring now to FIG. 2, the network manager 1 is 
provided with the RPM system 20 which provides the 
functionality required for troubleshooting, performance 
monitoring, service level planning and provisioning of paths 
and/or network elements 24 for any source-destination route 
in the IP network 10. The RPM system 20 is comprised of 
a management server 22 for providing the RPM function- 
ality described above which is connected to an external 
database 25. The RPM system 20 also has a standard SNMP 
data collector (hereinafter simply referred to as "data 
collector") 21 connected to the management server 22 which 
is responsible for handling SNMP communications between 
the management server 22 and the network elements 24 of 
the IP network 10, and a graphical user interface (GUI) 23 
connected to the management server 22 for allowing a user 
to readily access and make use of the RPM functionality for 
managing the IP network 10 at a network level. 

According to a preferred embodiment, the RPM system 
20 is incorporated in the network manager 1 as an add-on to 
the device -level network management functionality pro- 
vided by a well-known standard network management appli- 
cation referred to as integrated network management (INM) 
26. As such, for the RPM system 20 description provided 
below, it is to be assumed that the RPM system 20 is 
designed to be launched from INM 26. It is to be understood 
that the RPM system could alternatively be designed as an 
add-on to other network management applications or in the 
further alternative, as a stand-alone network management 
application. The specific steps required to implement the 
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RPM system 20 as a stand-alone network management 
application or the steps to integrate the RPM system 20 into 
INM 26 or any other network management application 
would be obvious to a person skilled in the art and, as such, 

S is not described here in any detail. 

Referring now to FIG. 3, there is illustrated the GUI 23 
used according to the preferred embodiment of this inven- 
tion to enable a GUI user to specify and monitor routes, 
paths and associated network elements. When operational, 

10 the GUI 23 produces a main computer window which is 
subdivided into 5 sections. More specifically, sections 30, 
31, 32 of the main is computer window are located on the 
left hand side of the main computer window to form a left 
handed pane while sections 4 and 5 are located on the right 
hand side of the main window forming a right handed pane, 
Sections 30, 31, 32 of the left handed pane each 20 
contains a respective table. In particular, section 30 contains 
a table which can be used by the GUI user to specify the 
routes to be monitored (hereinafter the "route table"). In 

2Q order to specify a particular route, the route table of section 

30 contains 3 column fields in which a GUI user can enter 
the parameters associated with that route. More specifically, 
the first column field corresponds to the route name, the 
second column field corresponds to the route source IP and 

25 the third column field corresponds to the route destination IP. 
Section 31 contains a table (hereinafter the "path table") 
for displaying the paths associated with a particular route 
when the route is selected in the route table 30 by the GUI 
user. The path table 31 contains a path colour column and a 

30 path name column for identifying each path of the selected 
route with a particular colour and name. 

Section 32 contains a table (hereinafter the "path instance 
table") for displaying the paths instances associated with a 
particular path when the path is selected in the path table 31 

35 by the GUI user. Each path instance provides the parameters 
of a particular path for a given time. The path instance table 

32 contains 5 column fields for the following path attributes: 
(1) time stamp, (2) path direction, (3) percentage of 
utilization, (4) errors and discards and (5) latency. 

40 Sections 33 and 34 of the right handed pane each contains 
a respective notepad for graphically displaying RPM results 
corresponding to the routes and paths specified in tables 30, 

31 and 32. 

In particular, section 33 contains a notepad for graphically 
45 displaying the nodes, interfaces and links of the routes and 
paths selected in tables 30,31 and 32. The notepad of section 

33 has 3 display modes, namely a linear graphics mode, a 
route network graphics mode and a network graphics mode. 
These modes are selectively enabled by way of a respective 

50 pull-down menu located in a top portion of section 33. 

In the linear graphics mode, the selected route and its 
associated paths, nodes and interfaces are shown in the 
notepad of section 33 on a straight line without regard to the 
actual layout of the IP network 10. Based on the parameters 

55 specified in tables 30, 31, 32, three display scenarios are 
possible. First, when a route is selected in the route table 30, 
only the source and destination nodes are shown in the 
notepad of section 33 secondly, when a path of a particular 
route specified in the route table 30 is selected in the path 

60 table 31, all the nodes and interfaces associated with the path 
selected are shown on a straight line in addition to the source 
and destination nodes. Thirdly, when a path instance of a 
particular path selected in the path table 32 is selected in the 
path instance table 32, all the nodes and interfaces of the 

65 forward path are shown on a top straight line and all the 
nodes and interfaces of the backward path are shown on a 
bottom straight line below the forward path. 
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In the route network graphics mode, the selected route and monitoring logic (T&ML) unit 41 for the real-time and 
its associated paths, nodes and interfaces are shown in the historical tracing of a specified route, a performance moni- 
notepad of section 33 where the nodes; and interfaces are to ring logic (ML) unit 42 for monitoring the performance of 
displayed as positioned in the IP network 10. In other words, the paths associated with a specified route and a historical 
the location of the nodes and interfaces as displayed in the 5 path & performance broker 43 for analyzing past trace and 
notepad of section 33 is representative of their actual loca- performance results. The management also has a collector 
tion in the IP network 10. interface (communication layer) 40, a database (DB) man- 
In the network graphics mode, the paths, nodes and ager 46, a request dispatcher 45, a server remote method 
interfaces of all the routes specified in the route table 30 are invocation (RMI) interface 47 and a notification channel 44 
displayed in the notepad of section 33 in the same manner 1Q all interconnected with the path T&ML unit 41, the path & 
25 the selected route and its associated paths, nodes and performance broker 43 and the performance ML unit 42 in 
interfaces are shown in the route network graphics mode i.e. the following manner. The collector interface 40 is exter- 
the nodes and interfaces are displayed as positioned in the IP nally connected to the data collector 21 through an RMI 
network 10. interface 50 and internally connected to both the path T&ML 
Section 34 of the right handed pane also contains a i5 unit 41 and the performance ML unit 42. The path T&ML 
notepad for graphically displaying real-time and history unit 41 is connected to the performance ML unit 42 and also 
performance charts for any one of the routes; specified in the to the notification channel 44. The notification channel 44 is 
route table 30 or any one of its associated paths, nodes or externally connected to the GUI 23 via the RMI 48 internal 
interfaces. to the GUI 23. The performance ML unit 42 is also con- 
According to the preferred embodiment of the invention, 2Q nected to the notification channel 44 and to the DB manager 
the GUI 23 is designed to allow the GUI user to specify the 46 providing connectivity with the database 25 external to 
rate at which the selected route and paths are to be moni- the management server 22 through an interface 49. The 
tored. The monitoring rate is defined by the rate at which the management server 22 also has the request dispatcher 45 
network elements are polled by the management server 22 connected to receive requests from the GUI 23 via the server 
(see below) which corresponds to the rate at which the 25 RMI 47 internal to the management server 22. The request 
information in the GUI 23 is to be updated. This rate is dispatcher 45 is connected to the DB manager 46, the path 
hereinafter referred to as the polling rate and for the GUI 23 T&ML unit 41, the historical path & performance broker 43 
of the present invention, this rate is set to 10 minutes. and the performance ML unit 42. 

In operation, the tables 30, 31, 32 and the section 33 and The following section will now describe in detail and in 
34 notepads are empty. In order to specify a particular route, 30 reference to FIGS. 5 through 10 the operation of the man- 
the GUI user enters the parameters associated with that route agement server 22 in terms of the architecture and function- 
in the route table 30 and in particular, the route name, the ality of each of its path T&ML unit 41, historical path & 
route source IP and the route destination IP, As the GUI user performance broker 43 and performance MD unit 42. 
wishes to monitor more routes, these routes can also be Referring firstly to FIG. 5, tile RPM system 20 shown 
specified in the route table 30 by entering their respective 35 with a more detailed block diagram of the path T&ML unit 
route parameters i.e. the route name, the route source IP and 41 as implemented in the management server 22 for pro- 
file route destination IP. viding real-time and historical tracing of a specified route. In 
Once the desired routes have been specified into the route particular, the path T&ML unit 41 is comprised of a path 
table 30, each particular route contained therein may then be trace handler 55, a source and destination register 56, a path 
selectively monitored at the rate specified by the monitoring 40 objects assembler 57, a "get next hop" logic block 58, a 
rate (see above). In order to monitor a particular route, the queuing manager 60, and a path change monitor logic 59 all 
route must first be selected (highlighted) in the route table interconnected within the management server 22 as follows. 
30. As this occurs, all the paths associated with that par- The path trace handler 55 is connected to the request 
ticular route will appear in the path table 31. When a path is dispatcher 15 and to the DR manager 46. The source and 
selected among the paths contained in the path table 31, all 45 destination register 56 is connected to the queuing manager 
of the instances of the selected path will be displayed in the 60 and to the path objects assembler 57. The path objects 
path instance table 32. As a result, each path instance of the assembler 57 is, in turn, connected to the get next hop logic 
selected path will be displayed showing the parameters of 58 and the path change monitor logic 59. The path change 
the selected path for specific times. The notepads in sections monitor logic 59 is coupled to the DB manager 46, the 
33 and 34 can be used thereafter for monitoring the perfor- 50 notification channel 44, the performance ML unit 42 and the 
mance and path changes of the path instances listed in the get next hop logic 58. The get next hop logic 58 is externally 
path instance table 32. connected to the data collector 21 via the collector interface 

Referring now to FIG. 4, there is illustrated a more 40. 

detailed block diagram of the RPM system 20 of FIG. 2. The real-time tracing operation of the management server 

Briefly stated, the RPM system 20 provides real-time and 55 22 is triggered when the user requests, through the GUI 23, 

historical tracing of routes and paths specified by a user that a particular route be traced in real-time. The request 

through the GUI 23 as well as real-time and historical dispatcher 45 receives the user's request and places it into 

performance monitoring of the routes and paths specified. the path trace handler 55. The path trace handler 55 operates 

The route tracing and performance monitoring functionality to separate the route tracing request into its constituent 

is embodied in the management server 22 to provide the 60 source and destination endpoint components and subse- 

network manager 1 with the added capability of quently forwards them to the DB manager 46. Upon receipt, 

troubleshooting, performance monitoring, service level the DB manager 46 requests from the database 25 all the 

planning and provisioning paths between any source- associated source and destination objects interfaces for the 

destination endpoints (routes) in the IP network 10 of FIG. source and destination endpoint components of the specified 

1. 65 route. 

In order to carryout the above-mentioned functionality, Once captured from the database 25, the DB manager 46 

the management server 22 is comprised of a path trace & places the source and destination objects into the queuing 
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manager 60 which is responsible for queuing and processing 
route tracing requests according to a high priority, a real- 
time priority, a historical high priority or a historical low 
priority. For a real-time trace routing request, the DB man- 
ager 46 places the source and destination objects of the route 
specified by the user into the queuing manager's real-time 
queue for processing. When the queuing manager samples 
the real-time queue, it then draws the source and destination 
objects associated with the specified route and sends them 
into the source and destination register 56 for further pro- 
cessing. 

For each of the source endpoint and intermediate points 
located between the source endpoint and the destination 
endpoint, the path objects assembler 57 asks the get next hop 
logic 58 (further details below) to find the next hop to the 
destination endpoint until it actually hits the destination 
endpoint. This results in the discovery (assembly) of all the 
paths used in real- time by traffic being transmitted on the 
specified route from the source endpoint to the destination 
endpoint, each path being defined as a manageable object 
containing a respective set of network devices) and associ- 
ated interfaces located between the source endpoint and the 
destination endpoint of the specified route. These paths are 
hereinafter referred to as "forward paths". This path discov- 
ery process is repeated for assembling the paths used for 
transmitting traffic from the destination endpoint to the 
source endpoint (hereinafter referred to as "backward 
paths"). 

For each forward and backward path assembled, the path 
objects assembler 57 places the corresponding constituent 
network devices and associated interfaces into a respective 
path list for notification back to the user which can then 
access this information via the GUI 23 (see above). The path 
objects assembler 57 also operates to temporarily store the 
results of the paths discovered into the database 25 through 
the DB manager 46 in order to save the results of the 
real-time tracing operation for real-time performance analy- 
sis. The path objects assembler 57 then informs the perfor- 
mance ML unit 42 to begin sending real-time performance 
data back to the user through the GUI 23 (further details 
below). 

As routing in a network is dynamic, the paths discovered 
for the route specified are monitored periodically by the path 
change monitor logic 59 for path changes. In particular, the 
paths are rediscovered and checked against the existing 
paths at the polling rate specified by the user in the GUI 23. 
If the rediscovered paths differ from the existing paths in any 
way (by a single network device or a single interface), this 
causes the paths to be updated or new paths to be associated 
with the specified route. If there is any path changes, an 
alarm is generated by the path change monitor logic 59 for 
the GUI user through the notification channel 44. 

There may be situations where path changes occur 
between polling events which are worthy of notification to 
the GUI user. To address these situations, the RPM system 
20 is designed with the ability to handle traps generated by 
network elements 24 and notify the GUI user of significant 
events. 

Traps generated by network elements 24 are received into 
the management server 22 through a trap gatherer 61 which 
is preferably implemented in the data collector 21. The trap 
gatherer 61 forwards each trap received to a trap handler 62 
which is internal to the management server 22. Upon receiv- 
ing a trap from a particular network element 24, the trap 
handler 62 requests that all paths associated with that 
particular network element 24 be placed into the high 
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priority queue for processing so that the GUI user can be 
notified of the changes. 

In order to trigger the historical tracing operation of the 
management server 22, the user has to request, through the 

S GUI 23, that a particular route be monitored so that the 
results of the tracing operation be saved permanently in the 
database 25 for subsequent historical analysis. Similarly to 
the real-time tracing operation of the management server 22, 
the user's historical route trace request is received in the 

10 request dispatcher 45 which places it into the path trace 
handler 55. The path trace handler 55 operates to separate 
the historical trace route request into its constituent source 
and destination endpoint components and subsequently for- 
wards them to the DB manager 46. Similarly to the manner 
in which a real-time route trace request is processed, the DB 

15 manager 46 then requests and captures from the database all 
the associated source and destination objects (interfaces) for 
the source and destination endpoint components of the 
specified route and registers each object pair as a historical 
monitored route into a route list maintained in the database 

20 25 for all historical monitored routes. 

In order to service the user's historical route trace request, 
the queuing manager 60 periodically requests that the DB 
manager 46 provides it with a list of all source and desti- 
nation object pairs stored in the route list of the database 25 

25 and places them in its low priority queue. The queuing 
manager 60 will then sequentially send, in accordance with 
its defined priority levels, the low priority object pairs 
queued to the source and destination register 56 for process- 
ing and subsequent forwarding to the path assembler 57. The 

30 path objects assembler 57 operates in the same tanner it 
operates when assembling (discovering) paths in response to 
a real-time route trace request. Accordingly, in this case, the 
path objects assembler 57 operates to assemble all of the 
forward and backward paths associated with the route 

35 specified, requests that the path change monitor logic 59 
monitor the paths discovered at the polling rate and notify 
the user via the notification channel 44 of any path changes 
observed as a result of a new poll or a trap received from the 
IP network 10. 

40 However, in contrast to real-time operations, the path 
objects assembler 57 operates to permanently store the 
results of the paths discovered into the database 25 through 
the DB manager 46 in order to save the results of the 
historical tracing operation. By sending an appropriate 

45 request to the management server 22, the GUI user can then 
obtain the historical information stored for subsequent his- 
torical performance analysis. 

To further explain the real-time and historical tracing 
operation of the management server 22, a flowchart is shown 

50 in FIG. 6 illustrating the main steps performed by the 
management server 22 in servicing a real-time or historical 
route tracing request for discovering the paths of the route 
specified. From this flowchart, it can be observed that the 
tracing operation of a particular route is triggered by the user 

55 which specifies the source and destination endpoints of the 
route. It can also be observed that if historical monitoring is 
performed, the source and destination endpoints of the 
specified route are permanently saved in the database 25 
(FIG. 5) for subsequent historical analysis. It can still be 

60 further observed that for each of the source endpoint and 
intermediate points located between the source endpoint and 
the destination endpoint which are traversed by traffic trav- 
elling from the source endpoint and the destination endpoint, 
all the associated forward paths are discovered. It can still be 

65 further observed that this path discovery process is repeated 
for the backward paths associated with the particular route 
specified. 
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As noted above in reference to FIG. 5, the forward paths According to the preferred embodiment of the present; 

and backward paths are assembled by running a path trace invention, the real- time performance monitoring operation 

algorithm. This particular algorithm is run by the get next of the management server 22 is triggered as the user 

hop logic 58 of FIG. 5 which, for the source endpoint or anus requests, through the GUI 23, that the performance of a 

of the intermediate points located between the source end- 5 particular route be monitored in real-time. This usually 

point and the destination endpoint, operates to find the next occurs after the specified route has been traced in real- time 

intermediate point (hop) to the destination endpoint until it when the path objects assembler 57 of the path T&ML unit 

actually hits the destination endpoint. This involves 41 (see FIG. 5) requests the performance ML unit 42 to 

sequencing through each intermediate point located between begin sending real-time performance data back to the user 

the source endpoint and the destination endpoint of the ao through the GUI 23. 

specified route and gathering routing and interface informa- When such a request is initiated, it is received in the 

tion specific to each intermediate point. The information monitoring queue 65 which, as a result, proceeds to update 

gathered is then processed by the path objects assembler 57 the information contained in each of the route, path and 

(see FIG. 5) for assembling the paths associated to the objects queues 66, 67, 68 with new identification data which 

specified route. 15 was previously temporarily stored in the database 25 by the 

To further describe this, reference is now made to FIG. 7 path objects assembler 57 (FIG. 5) in executing the associ- 
which contains a flowchart of the sequencing operation of ated request for real-time tracing of the route specified. This 
the path trace algorithm referred to above. Prom this new identification data is added to the existing (old) iden- 
flowchart, it can be observed that based on the particular tification data contained the corresponding queue 66, 67, 68. 
source endpoint specified by the GUI user, the path trace 2 o object performance logic 69 begins polling each net- 
algorithm initially runs a device discovery routine for gath- work object listed in the object queue 68 (new and old) 
ering identification information about that particular source through the data collector 21 to obtain performance data for 
endpoint. Next, an interface discovery routine is run for each of the objects listed. The object performance logic 69 
determining the input interface associated with the particular then forwards the polled responses obtained to the notifica- 
source point specified. Next, the path trace algorithm runs a 25 *ion channel for notification to the GUI 23. 
routing information discovery routine for obtaining infor- The polled responses are also sent to the path performance 
mation about the manner in which the source endpoint logic 70 together with the polled objects where the objects 
routes traffic intended for the destination endpoint. Next, the polled are compared to threshold data contained in the path 
path trace algorithm runs a get next hop discovery routine to queue 67 and performance for each of the paths listed therein 
find the next hop in the path to the destination endpoint 30 is calculated. The path performance logic 70 will then notify 
which is followed by a leave interface discovery routine run the route performance logic 71 that it has completed the path 
to determine the particular output interface associated with performance analysis for the particular objects polled and 
the source endpoint. Next, the next hop is compared to the forward its performance results to the notification channel 
destination endpoint supplied by the GUI user and if the next 44 for transmission to the GUI 23. The path performance 
hop is the destination endpoint, a path to the destination 35 logic 70 also proceeds to forward its performance results 
endpoint is found and reported to the path objects assembler together with the paths for which performance was calcu- 
57. If the next hop is not the destination endpoint, then the la ted to the route performance logic 71 which compares the 
next hop is fed back into the path trace algorithm which runs paths obtained from the path performance logic 70 with the 
again for determining the next hop in the path to the old identification data contained in the route queue 66 and 
destination endpoint. This process is repeated until the next 40 calculates an overall route performance metric which is then 
hop becomes the destination endpoint at which time, as transmitted to the GUI 23 through the notification channel 
noted above, the path found is reported to the path objects 44. The real-time monitoring operation of the management 
assembler 57 (FIG. 5). server 22 just described above is repeated at the polling rate 

Referring now to FIG. 8, there is illustrated a more specified by the user through the GUI 23. 

detailed block diagram of the performance ML unit 42 of 45 Referring now to FIG. 9, there is illustrated a more 

FIG. 4 as implemented in the management server 22 for detailed block diagram of the performance ML unit 42 of 

providing real-time performance monitoring of a specified FIG. 4 as implemented in the management server 22 for 

route. providing historical performance monitoring of a specified 

The performance ML unit 42 is comprised of a monitoring route. The route queue 66, a path queue 67 an object queue 

queue 65 externally connected to both the request dispatcher 50 68 described above are also used by the performance ML 

45 and the DB manager 46 and internally connected to a unit 42 for historically monitoring the performance of a 

route queue 66, a path queue 67 and an object queue 68. specified route. It will be recalled that the queues 66, 67, 67 

These queues 66, 67, 68 are respectively used for holding are respectively used for holding identification data related 

identification data related to routes, paths and associated to routes, paths and associated objects (network devices, 

objects (network devices, interfaces, etc.) which is periodi- 55 interfaces, etc.). As will be described below, this identifica- 

cally updated from the database 25 each time a real-time tion data is periodically updated from the database 25. The 

performance monitoring request comes in from the request route, path and object queues 66, 67, 68 are respectively 

dispatcher 45 (further details below). The route path and connected to a corresponding route, path and object perfor- 

object queues 66, 67, 68 are respectively connected to a mance monitor logic 74, 73, 72. The object performance 

corresponding route, path and object performance logic unit 60 monitor logic unit 72 is externally connected to the data 

70, 71, 69. The object performance logic unit 69 is externally collector 21 through the communication layer 40 and also 

connected to the data collector 21 through the communica- internally connected in series to the path and the route 

tion layer 40 and also internally connected in series to the performance monitor logics 73, 74. Finally, each of the 

path and the route performance logic units 70, 71. Finally, route, path and object performance monitor logics 74, 73, 72 

each of the route, path and object performance logic units 65 is externally connected to the notification channel 44. 

71, 70, 69 is externally connected to the notification channel The historical performance monitoring operation of the 

44. management server 22 is initially triggered by a request 
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from the user, through the GUI 23, that the performance of register 83, an event & performance gatherer 82, a solution 

a particular route be historically monitored. Upon being provider 84 and a calculation server 85 all interconnected 

requested to initiate historical performance monitoring of a within the management server 10 as follows. The path trace 

specified route, the historical performance ML unit 42 polls handler 80 is externally connected to the request dispatcher 

the associated objects through the data collector 21, com- 5 45 and the DB manager 46, Also externally connected to the 

putes the performance of each of the objects polled and with DB manager 46 is the path gatherer 81 and the event & 

these results, computes the performance of each path asso- performance gatherer 82. The path gatherer 81 is also 

ciated with the specified route and again with these results, connected to the information register 83, the event & per- 

computes the performance of the specified route itself. All of formance gatherer 82 and the solution provider 84 while the 

these performance results are permanently saved in the 3Q event & performance gatherer 82 is also connected to the 

database 25 for subsequent historical analysis. calculation server 85. Lastly, in addition to being connected 

More specifically, when a historical performance moni- to the path gatherer 81, the information register 83 is also 

toring request is initiated, it is received in the monitoring externally connected to the queuing manager 60. 

queue 65 which, as a result, proceeds to update the infor- As noted above, the historical path & performance broker 

mation contained in each of the route, path and objects 43 allows the user to retrieve the historical performance or 

queues 66, 67, 68 with new identification data which was 15 route data associated with a particular route which has been 

previously permanently stored in the database 25 by the path collected and permanently stormed in the database following 

objects assembler 57 in executing the associated request for the execution of previous historical route trace requests or 

historical tracing of the route specified. This new identifi- historical performance monitoring requests. In order to do 

cation data is added to the existing (old) identification data the ^ kitiates a throu S h the GUI 23 s P ed " 

contained the corresponding queue 66, 67, 68. 20 fymg a particular route and the desired time period for which 

The object performance monitor logic 72 begins polling >toncal performance data or route data is to be 

u * 1 u.* * 1* 4 J ■ *i_ • • , f a t j retrieved. The user s request is received in the request 

^ \l l.u ° f , m thC ; ° J uf 68 (nCW , and dispatcher 45 which places it into the path trace handler 80. 

old) through 1 the data collector 21 tc ^bUin performance data ^ path trace handler 80 operates t0 extract from lhe 

for each of the objects listed. The object performance ^ historical retrieval request the specified time period and the 

monitor logic 72 then forwards the polled responses source and destination endpoint components defining the 

obtained from the data collector 21 to the notification rcm te for which historical data is to be retrieved she path 

channel for notification to the GUI 23. The polled responses trace handler 80 subsequently forwards them to the DE 

are also sent to the path performance monitor logic 73 manager 46 which then requests and captures from the 

together with the polled objects where the objects polled are 3Q database 25 all the paths associated with the specified source 

compared to the old identification data contained in the path and destination endpoint components of the specified route 

queue 67 and performance for each of the active paths listed for the desired time period. 

therein is calculated. The path performance monitor logic 73 Once captured from the database 25, the DB manager 46 

will then notify the route performance monitor logic 74 that places the paths into the queuing manager 60 for processing, 

it has completed the path performance analysis for the 35 The queuing manager 60 will then sequentially send, in 

particular objects polled and forward its performance results accordance with its defined priority levels, the paths queued 

to the notification channel 44 for transmission to the GUI 23. to the information register 83 for further processing. The 

The path performance monitor logic 773 also proceeds to path gatherer 81 then reads the paths from the information 

forward its performance results together wish the paths for register 83 and, for each path read, requests the event & 

which performance was calculated to the route performance 40 performance gatherer 82 to retrieve all associated routing 

monitor logic 74 which compares the paths obtained from events and performance information from the database 25. 

the path performance logic 73 with the old identification The event & performance gatherer 82 together with the 

data contained in the route queue 66 and calculates an solution provider 84 operate to process the data collected 

overall route performance metric which is then transmitted from the database 25 into a format suited for use by the GUI 

co the GUI 23 through the notification channel 44. 45 23 through the notification channel 44. 

The performance of the specified route and each of the Referring now to FIG. 11, there is shown a second 

associated paths and objects is also measured against appro- embodiment of the RPM system 20 where a MIB 90 is also 

priate performance thresholds located in the threshold cross- used to temporarily store the routing and performance 

ing logic 75. If any performance threshold is breached for information gathered by the management server 22. In order 

any of the objects, paths or the specified route itself, the user 50 to store this information, the MIB 90 also has defined the 

is notified through the notification channel 44. Once the network-level concepts of routes and paths as manageable 

threshold calculations have been completed, the historical objects. These routes and paths objects can then be accessed 

performance monitoring process described above is carried by SNMP agents of other network elements 24 of the IP 

out again to obtain new performance values which are also network 10 or any other network entity/application which 

permanently stored in the database and checked against 55 may benefit from that information. The implementation of 

appropriate performance thresholds. The historical perfor- MIBs such as the MIB 90 is well known and is not described 

mance monitoring process is repeated until terminated by here in any detail. 

the user via the GUI 23. The RPM system functionality described above is imple- 

Referring now to FIG. 10, the historical path & perfor- mented in the network manager 1 by programming a general 

mance broker 43 as implemented in the management server 60 purpose computer (not shown). It is understood that the 

22 allows the user to retrieve the historical route and preparation of the programs necessary to accomplish this 

performance data respectively collected and permanently RPM functionality is obvious to persons of ordinary skilled 

stored in the database 25 as a result of carrying out historical in the network management art, particularly in view of the 

route trace requests and historical performance monitoring detailed description of the functionality of the management 

requests. 65 server 22 provided above in reference to FIGS. 4 through 9. 

The historical path & performance broker 43 is comprised While the invention has been described above with ref- 

of a path trace handler 80, a path gatherer 81, an information erence to a particular type of network, further modifications 
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and improvements to support other types of networks which 
will occur to those skilled in the art, may be made within the 
purview of the appended claims, without departing from the 
scope of the invention in its broader aspect. 

In particular, the invention has been described above with 
respect to an IP network. It is understood that the invention 
could also be applied to other types of networks. Further, the 
invention is not restricted to SNMP networks with an INM 
management platform and could also be used with manager- 
agent environments different from SNMP and in association 
with other management platforms. 

The RPM system has been described above with reference 
to a particular GUI design. It is to be understood that other 
GUI designs may also be used to enable a GUI user to 
specify and monitor routes, paths and associated interfaces 
in a network in accordance with the present invention. As an 
example, the GUI has been described above as having a 
main computer window which is subdivided into 5 sanctions 
for entering the RPM monitoring parameters and viewing 
the corresponding RPM results. It is to be understood that 
the computer window could be subdivided into more or less 
than 5 sections according to the GUI user's specific man- 
agement needs. 

It is also to be understood that other types of user 
interfaces may be used. For example, a command line 
interface (CLI) could be used. Moreover, the user interface 
has been described as being separate from the management 
server. It is to be understood that if necessary, the user 
interface may also be implemented internally to the man- 
agement server and still fall within the purview of the 
present invention. 

We claim: 

1. A route and path management (RPM) system for a 
communication network comprising a plurality of network 
elements whereby the network elements form multiple sets 
of paths, each set of paths being associated with a respective 
route in the communication network, the RPM comprising: 
a data collector for collecting data from the plurality of 
network elements whereby the data collected relates to 
at least one route and an associated set of paths formed 
in the communication network; 
a management server connected to the data collector to 
receive the data collected for monitoring the at least 
one route and the associated set of paths formed in the 
communication network; and 
a user interface connected to the management server for 
specifying the at least one route to monitor and report- 
ing the routing performance and path changes associ- 
ated therewith; 
wherein for monitoring the at least one route and the 
associated set of paths defined in the communication 
network, the management server is comprised of: 
a path trace and logic unit connected to the user 
interface for receiving the at least one route to 
monitor and performing historical and real-time 
monitoring of the path changes of the associated set 
of paths; and 

a performance monitor logic unit connected to the user 
interface for receiving the at least one route to 
monitor and for monitoring the performance of the at 
least one route and the associated set of paths his- 
torically and in real-time; and 

wherein for performing historical and real-time moni- 
toring of path changes of the associated set of paths, 
the path trace and monitor logic unit is comprised of: 
a trace handler for receiving the at least on route 
specified from the user interface; 
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a path objects assemble for assembling the set of 
paths associated with the at least on route speci- 
fied; and 

a path change monitor logic unit for monitoring 
changes in the set of paths associated with the at 
least on route specified. 

2. A route and path management (RPM) system for a 
communication network comprising a plurality of network 
elements whereby the network elements form multiple sets 
of paths, each set of paths being associated with a respective 
route in the communication network, the RPM comprising: 

a data collector for collecting data from the plurality of 
network elements whereby the data collected relates to 
at least one route and an associated set of paths formed 
in the communication network; 

a management server connected to the data collector to 
receive the data collected for monitoring the at least 
one route and the associated set of paths formed in the 
communication network; and 

a user interface connected to the management server for 
specifying the at least one route to monitor and report- 
ing the routing performance and path changes associ- 
ated therewith; 

wherein for monitoring the at least one route and the 
associated set of paths defined in the communication 
network, the management server is comprised of: 
a path trace and monitor logic unit connected to the user 
interface for receiving the at least one route to 
monitor and performing historical and real-time 
monitoring of the path changes of the associated set 
of paths; and 

a performance monitor logic unit connected to the user 
interface for receiving the at least one route to 
monitor and for monitoring the performance of the at 
least on route and the associated set of paths histori- 
cally and in real-time; and 

wherein for historically monitoring of the performance 
of the at least one route and the associated set of 
paths, the performance monitor logic unit is com- 
prised of: 

a monitoring queue for receiving the at least one 
route specified from the user interface and holding 
identification and performance data related to the 
at least one route specified and the associated set 
of paths; 

an object performance monitor logic unit connected 
to the monitoring queue for polling the network 
elements forming the associated set of paths for 
new identification and performance data; 

a path performance monitor logic unit connected to 
both the monitoring queue and the object perfor- 
mance monitor logic unit for computing the per- 
formance associated with each path of the set of 
paths; 

a route performance monitor logic unit connected to 
both the monitoring queue and the path perfor- 
mance monitor logic unit for computing the over- 
all performance of the at least one route specified; 
and 

a threshold crossing logic unit connected to the 
object performance monitor logic unit, the pat 
performance monitor logic unit and the route 
performance monitor logic unit for measuring the 
performance of the at least specified route and the 
associated set of paths against suitable perfor- 
mance thresholds. 

3. A route and path management (RPM) system for a 
communication network comprising a plurality of network 
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elements whereby the network elements form multiple sets 
of paths, each set of paths being associated with a respective 
route in the communication network, the RPM comprising: 
a data collector for collecting data from the plurality of 
network elements whereby the data collected relates to s 
at least one route and an associated set of paths formed 
in the communication network; 
a management server connected to the data collector to 
receive the data collected for monitoring the at least 
one route and the associated set of paths formed in the 10 
communication network; and 
a user interface connected to the management server for 
specifying the at least on route to monitor and reporting 
the routing performance and path changes associated 
therewith; 5 
wherein for monitoring the at least on route and the 
associated set of paths defined in the communication 
network, the management server is comprised of: 
a path trace and logic unit connected to the user 
interface for receiving the at least one route to 
monitor and performing historical and real-time 20 
monitoring of the path changes of the associated set 
of paths; and 

a performance monitor logic unit connected to the user 
interface for receiving the at least on route to monitor 
and for monitoring the performance of the at least on 25 
route and the associated set of paths historically and 
in real-time; and 

wherein for monitoring the performance of the at least 
one route and the associated set of paths in real-time, 
the performance monitor logic unit is further com- 30 
prised of: 

an object performance logic unit connected to the 
monitoring queue for polling the network ele- 
ments forming the associated set of paths for new 
identification and performance data; 35 
a path performance logic unit connected to both the 
monitoring queue and the object performance 
logic unit for computing the performance associ- 
ated with each path of the set of paths; and 
a route performance logic unit connected to both the 
monitoring queue and the path performance logic 40 
unit for computing the overall performance of the 
at least one route specified. 
4. A route and path management (RPM) system for a 
communication network comprising a plurality of network 
elements whereby the network elements form multiple sets 45 
of paths, each set of paths being associated with a respective 
route in the communication network, the RPM comprising: 
a data collector for collecting data from the plurality of 
network elements whereby the data collected relates to 
at least one route and an associated set of paths formed 50 
in the communication network 
a management server connected to the data collector to 
receive the data collected for monitoring the at least 
one route and the associated set of paths formed in the 
communication network; and 55 
a user interface connected to the management server for 
specifying the at least one route to monitor and report- 
ing the routing performance and path changes associ- 
ated therewith; 

wherein for monitoring the at least one route and the 60 
associated set of paths defined in the communication 
network, the management server is comprised of; 
a path trace and logic unit connected to the user 
interface for receiving the at least one route to 
monitor and performing historical and real-time 65 
monitoring of the path changes of the associated set 
of paths; and 
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a performance monitor logic unit connected to the user 
interface for receiving the at least one route to 
monitor and for monitoring the performance of the at 
least on route and the associated set of paths histori- 
cally and in real-time; and 
wherein the management server further comprises a 
historical path and performance broker connected to 
the user interface for historically analysing the rout- 
ing performance and the path changes of the at least 
one route and the associated set of paths, the histori- 
cal path and performance broker comprising: 
a trace handler for receiving the at least one route 

specified from the user interface; 
a path gatherer for retrieving the set of paths asso- 
ciated with the at least one route specified; 
an event and performance gatherer for gathering the 
routing performance data and the path changes of 
the at least one route and the associated set of 
paths, and 

a solution provider for processing the routing per- 
formance data and the path changes of the at least 
one route and the associated set of paths in a form 
appropriate for analysis. 

5. The RPM system of claim 1 wherein the data collector 
is operable with simple network management protocol 
(SNMP). 

6. The RPM system of claim 1 wherein the data collector 
is comprised of a trap gatherer for gathering the generated by 
network elements of the communication network. 

7. The RPM system of claim 6 wherein the management 
server further has a trap handler connected to the trap 
gatherer for handling the traps generated and notifying the 
user interface of significant events. 

8. The RPM system of claim 1 wherein the RPM system 
is operable with integrated network management (INM). 

9. The RPM system of claim 1 in combination with a 
database for storing the routing performance results of the at 
least one route and the path changes associated therewith. 

10. The RPM system of claim 9 in combination with a 
management information base (MIB) for providing SNMP 
access to the at least one route and the associated set of paths 
monitored. 

11. A method for managing routes and paths in a com- 
munication network comprising a plurality of network ele- 
ments whereby the network elements form multiple sets of 
paths, each set of paths comprising at least one forward path 
and one backward path and being associated with a respec- 
tive route defined by a source endpoint and a destination 
endpoint in the communication network, the method com- 
prising the steps of: 

collecting data from the plurality of network elements 
whereby the data collected relates to at least one route 
and an associated set of paths; and 

monitoring the at least one route and the associated set of 
paths; 

wherein the step of monitoring the at least one route and 
the associated set of paths comprises the steps of: 
performing historical and real-time monitoring of the 

path changes of the associated set of paths; and 
monitoring of the performance of the at least one route 

and the associated set of paths historically and in 

real-time; and 
wherein the step of performing historical and real-time 

monitoring of the path changes of the associated set 

of paths comprises the steps of: 

assembling each one of the set of paths; and 

monitoring the path changes of the associated set of 
paths historically and in real-time. 
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12. The method of claim 1 wherein the step of assembling 
each one of the set of paths comprises the steps of: 

at each of the source endpoint and subsequent interme- 
diate points located between the source endpoint and 
the destination endpoint, collecting routing information 
for assembling the at least one forward path of the set 
of paths; and 



20 



at each of the destination endpoint and subsequent inter- 
mediate points located between the destination end- 
point and the source endpoint, collecting routing infor- 
mation for assembling the at least one backward path of 
the set of paths. 
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